[meego-packaging] rejections FAQ - un-spectacle package isn't allowed

[Anas Nashif]

On 2010-07-30, at 8:08 AM, <fathi.boudra at nokia.com> <fathi.boudra at nokia.com> wrote:

> Hi,
> 
> We have this rule:
> - It is NOT mandatory to use spectacle for ALL packages
> 
> As I understand, you aren't forced to use spectacle
> (IMHO, the "for ALL packages" should be removed for clarity of the rule).

Yes, this needs to be changed.

> 
> Some days ago, I've seen this new rule:
> - un-spectacled package is rejected 

If there is  a valid reason, it should not be rejected. If you are the main maintainer and you agree to take full responsibility for it and think that spectacle does not support the sort of packaging requirements that package needs, then it should be fine. You should not start changing packages you do not maintain just for fun and just because you think it produces crap.

> 
> Let's say a maintainer/packager provides YAML files for most packages ;),
> it means on the next package update round, you don't have a choice anymore.
> 
> The package have been spectaclified and the maintainer/packager has enforced
> spectacle usage. Which rule take precedence?

> 
> IMHO, spectacle is a helper tool to make package, nothing more.
> His usage couldn't be enforced to the maintainers/packagers.
> 

I agree It is a helper tool and the main reason we have it is to enforce unified packaging. We have already seen that we all come from different backgrounds and how 1 packager is adding fedora macros and fedora packaging practices and the other is adding opensuse while someone else is trying to debianize rpms. Spectacle helps us have a unified packaging format and also helps us evolve very fast if something changes.

> I see here an attempt to force spectacle usage. Now, I see coming autospectacle.
> For both tools, the issue is similar: a lack of properly defined rules.

Ok, autospectacle can be nice if you are packaging something the first time, once you have the yaml/spec file you can decide how to go on from there. I do not see why such a tool would be required for every single minor version update, this will just cause lots of issues and instead of depending on a human reviewing changes we would be relying on a script and things can really go bad. I still want to see the human element here :)




> 
> For MeeGo project, we should have a set of rules and policies clearly
> identified and blessed by the required authority.

Ok, lets start and we should move this to the wiki:
- spectacle is not mandatory
- spectacle is recommended for simple packages
- packager should not change packaging format randomly. 
  - You need to be the main maintainer
  - You need to have a valid reason why not to use the yaml format
- autospectacle is not mandatory
- autospectacle is recommended for initial packaging 


We should probably expand on those.


Anas



> 
> Cheers,
> 
> Fathi
> 
> _______________________________________________
> MeeGo-packaging mailing list
> MeeGo-packaging at meego.com
> http://lists.meego.com/listinfo/meego-packaging