Re: [qooxdoo-devel] the contrib site
Excellent explaination of our workflow. We might use this text as a introduction on Bugzilla site? Greetz Christopher Von: thron7 [[email protected]] Gesendet: Mittwoch, 25. Juli 2012 16:34 An: qooxdoo Development Betreff: Re: [qooxdoo-devel] the contrib site On 07/25/2012 03:28 PM, panyasan wrote: > thron7-2 wrote >> On 07/25/2012 02:28 PM, panyasan wrote: >>> Great! I this a long-term project or a feature that will be implemented >>> soon? >> As nobody has created even a bug for it yet, nothing can be scheduled, >> so I wouldn't expect anything soon. >> >> > I can file a bug for this, if this is what you want ;-) But I am afraid that > alone won't make it happen, as long as you're not free to put developer time > behind it. So my question really was if that is a feature that has some sort > of priority. I would vote for it. People seem to misjudge the role of bugs in our project (although it is apparent enough if you've followed the project for a while): 1. Our workflow is driven by bugs/issues. Nothing really happens without a bug. We can discuss and analyse a lot on the mailing list. But without a bug you will hardly see any form of implementation, be that framework classes, documentation or project infrastructure. 2. Having a bug is by no means a guarantee that something will happen. It is a *necessary* but not a *sufficent* condition for it. But without a bug ... see 1. 3. Once a bug exists, you can greatly enhance its chances of being implemente by providing compelling use cases, background information, or even code. You can even vote for it. Others can do the same. Without a bug, nothing like this is possible. 4. Bugs might get scheduled (meaning they are assigned to a future release/"target milestone"). Only scheduled bugs get done (with few exceptions). Without a bug, an issue will never get scheduled ... see 1. 5. Users open bugs, not core developers. This is important. The core team opens bugs every now and again, but this is only second-best. Only a bug opened by a user *documents* a need from the community. Core developer-created bugs are sort of second-class citizens, as they always carry the connotation of something arbitrary, something you might or might not do, something with possibly questionable backing from the community. So you usually won't see us open bugs for you. 6. The core team playes the reactive part here. Bugs are scheduled, analyzed, prioritized, delayed, assigned or rejected. If there isn't a bug, nothing of this happens. So the question goes back to you, whether the new contrib system is something that *you* want :-). T. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
> Thanks, Thomas, for the clarification. This wasn't apparent to me, > although I > have been following the project for a long time (actually, since version > 0.5). Ok. And it wasn't like that from the start. I can't say exactly off the top of my head, but the issue tracker-centered workflow came later than 0.7, maybe with 1.0. > I can see the point of your reasoning, but it doesn't fully resemble what > I > have experienced so far. I always had the impression that you as the core > team had a very definite idea of what it was you were trying to achieve > and > of the features you wanted to implement. Yes, we have :-). All I wanted to say is if you got something that is close to *your* heart, make sure you create a bug for it; don't wait for us to do it. > Yes, there has been the > occasional > wish from the community, but the main ideas were always yours (driven by > company needs or own reasoning about what needed to be done). There are > plenty of bugs with feature requests that have been there forever [1]. That's the other thing I said. Creating a bug is necessary, but not sufficient for an implementation. Of course we are prioritizing issues, and quite a few get queued up at the back (and believe me, not just user-created ones). But I think by now you got me: Creating a bug is your best chance of getting considered. (As a side note, I appreciate when people raise issues on the mailing list first if they are not sure about their thoughts. But if there are no hard facts raised against the issue, opening a bug for it is then your best next move). > Don't get me wrong, I think this is perfectly ok and it is what has made > qooxdoo what it is. I wasn't fully aware of whether you filed bugs for > your > own targets or not. And it would seem to me that something like contrib2.0 > is not just about doing us a favor, but actually a very important > framework > decision that might have very beneficial consequences (in terms of number > of > contributions) I entirely agree, both for importance and not just doing the users a favour. But we are not talking here about important vs. unimportant - relevant vs. out-of-scope - feasible vs. not feasible; decisions like these are all too trivial. We are talking about important vs. more important - very relevant vs. highly relevant - feasible vs. feasible but with a greater impact. This is our usual scale of decisions to make. On the other hand we have "lost" two members of the core team during the first half of this year. I don't want to dramatize, but for a small team like us this has serious implications. We have just brought out our second major release, 2.0, and I think all our efforts now need to go into stabilizing and maturing this new incarnation of the framework. We have entered so many new fields with it, and the least thing I want to see now, less than anything else, is a decline in quality. We need to attack the rough edges... > But now I know more and I am happy to file that famous bug that got it all > started. :-) Very good :-). T. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
Ok, done: http://bugzilla.qooxdoo.org/show_bug.cgi?id=6674 -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580781.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
Thanks, Thomas, for the clarification. This wasn't apparent to me, although I have been following the project for a long time (actually, since version 0.5). I can see the point of your reasoning, but it doesn't fully resemble what I have experienced so far. I always had the impression that you as the core team had a very definite idea of what it was you were trying to achieve and of the features you wanted to implement. Yes, there has been the occasional wish from the community, but the main ideas were always yours (driven by company needs or own reasoning about what needed to be done). There are plenty of bugs with feature requests that have been there forever [1]. Don't get me wrong, I think this is perfectly ok and it is what has made qooxdoo what it is. I wasn't fully aware of whether you filed bugs for your own targets or not. And it would seem to me that something like contrib2.0 is not just about doing us a favor, but actually a very important framework decision that might have very beneficial consequences (in terms of number of contributions) But now I know more and I am happy to file that famous bug that got it all started. :-) [1] For example, http://bugzilla.qooxdoo.org/show_bug.cgi?id=5416, or a "Virtual Table" -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580780.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
> > thron7-2 wrote >> >> >> 1. Our workflow is driven by bugs/issues. Nothing really happens without >> a bug. We can discuss and analyse a lot on the mailing list. But without >> a bug you will hardly see any form of implementation, be that framework >> classes, documentation or project infrastructure. >> [...] >> >> > > Does this in other words mean that qooxdoo development (by the core team) > has basically come to a standstill as long as we don't file any bugs? No, I was specifically talking about issues raised by the community. Still, 1. is generally true as we are creating a whole slew of bug entries ourselves, for issues we have planned out of internal reasoning (which anybody can see following our issue tracker). But those were not what my post was about. T. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
thron7-2 wrote > > > 1. Our workflow is driven by bugs/issues. Nothing really happens without > a bug. We can discuss and analyse a lot on the mailing list. But without > a bug you will hardly see any form of implementation, be that framework > classes, documentation or project infrastructure. > [...] > > Does this in other words mean that qooxdoo development (by the core team) has basically come to a standstill as long as we don't file any bugs? -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580778.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
On 07/25/2012 03:28 PM, panyasan wrote: > thron7-2 wrote >> On 07/25/2012 02:28 PM, panyasan wrote: >>> Great! I this a long-term project or a feature that will be implemented >>> soon? >> As nobody has created even a bug for it yet, nothing can be scheduled, >> so I wouldn't expect anything soon. >> >> > I can file a bug for this, if this is what you want ;-) But I am afraid that > alone won't make it happen, as long as you're not free to put developer time > behind it. So my question really was if that is a feature that has some sort > of priority. I would vote for it. People seem to misjudge the role of bugs in our project (although it is apparent enough if you've followed the project for a while): 1. Our workflow is driven by bugs/issues. Nothing really happens without a bug. We can discuss and analyse a lot on the mailing list. But without a bug you will hardly see any form of implementation, be that framework classes, documentation or project infrastructure. 2. Having a bug is by no means a guarantee that something will happen. It is a *necessary* but not a *sufficent* condition for it. But without a bug ... see 1. 3. Once a bug exists, you can greatly enhance its chances of being implemente by providing compelling use cases, background information, or even code. You can even vote for it. Others can do the same. Without a bug, nothing like this is possible. 4. Bugs might get scheduled (meaning they are assigned to a future release/"target milestone"). Only scheduled bugs get done (with few exceptions). Without a bug, an issue will never get scheduled ... see 1. 5. Users open bugs, not core developers. This is important. The core team opens bugs every now and again, but this is only second-best. Only a bug opened by a user *documents* a need from the community. Core developer-created bugs are sort of second-class citizens, as they always carry the connotation of something arbitrary, something you might or might not do, something with possibly questionable backing from the community. So you usually won't see us open bugs for you. 6. The core team playes the reactive part here. Bugs are scheduled, analyzed, prioritized, delayed, assigned or rejected. If there isn't a bug, nothing of this happens. So the question goes back to you, whether the new contrib system is something that *you* want :-). T. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
thron7-2 wrote > > On 07/25/2012 02:28 PM, panyasan wrote: >> Great! I this a long-term project or a feature that will be implemented >> soon? > > As nobody has created even a bug for it yet, nothing can be scheduled, > so I wouldn't expect anything soon. > > I can file a bug for this, if this is what you want ;-) But I am afraid that alone won't make it happen, as long as you're not free to put developer time behind it. So my question really was if that is a feature that has some sort of priority. I would vote for it. -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580770.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
On 07/25/2012 02:28 PM, panyasan wrote: > Great! I this a long-term project or a feature that will be implemented soon? As nobody has created even a bug for it yet, nothing can be scheduled, so I wouldn't expect anything soon. > > If I understand correctly, by handling storage deliverables, you mean that > the planned feature will not upload stuff to github (like npm publish [1]) , Yes. > but only deal with URLs. Is that right? That would be perfectly fine. Correct. Catalog entries only URL-point to the place where the contrib is stored. Under this location there has to be a source tree or a zip archive. T. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
Great! I this a long-term project or a feature that will be implemented soon? If I understand correctly, by handling storage deliverables, you mean that the planned feature will not upload stuff to github (like npm publish [1]) , but only deal with URLs. Is that right? That would be perfectly fine. C. [1] http://npmjs.org/doc/publish.html -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580762.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
Ok, I do remember, now I am reassured. I was just reacting to the jQuery site which confused me. :-) -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580761.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
On 07/25/2012 11:53 AM, panyasan wrote: > I don't quite understand their approach. Why would you have to clone all of > this in order to add a contrib? > > I would much rather like it if the generator took care of everything and we > could use an npm-style approach to publishing, using the generator to > register contribs with a central repository. This is just a minor UI thing. But yes, the generator could be used as a frontend to maintain the meta data for a contrib in the contrib catalog. In contrast to npm there will be no storage handling of deliverables, though. T. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
On 07/25/2012 12:01 PM, panyasan wrote: > One use case comes to my mind: Imagine I want to move the trunk of my Dialog > contrib from sourceforge to github (as I actually do --- BTW sorry that the > trunk of this contrib is still buggy). Looking at the sf SVN, there would be > no way of knowing this, and keeping the wiki updated is a nuisance (I am so > lazy), and people wouldn't necessarily have a look. > > If, however, the config.json file just contained a reference to the name of > the contrib, and the central repository would know from where a particular > version of the contrib can be downloaded, this would avoid a lot of > confusion, rid the contrib users from having to deal with URLs etc. Maybe you have forgotten about the new design [1], but that's exactly the plan. T. [1] http://qooxdoo.org/contrib/qooxdoo-contrib2.0 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
One use case comes to my mind: Imagine I want to move the trunk of my Dialog contrib from sourceforge to github (as I actually do --- BTW sorry that the trunk of this contrib is still buggy). Looking at the sf SVN, there would be no way of knowing this, and keeping the wiki updated is a nuisance (I am so lazy), and people wouldn't necessarily have a look. If, however, the config.json file just contained a reference to the name of the contrib, and the central repository would know from where a particular version of the contrib can be downloaded, this would avoid a lot of confusion, rid the contrib users from having to deal with URLs etc. -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580755.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
I don't quite understand their approach. Why would you have to clone all of this in order to add a contrib? I would much rather like it if the generator took care of everything and we could use an npm-style approach to publishing, using the generator to register contribs with a central repository. Cheers, Christian -- View this message in context: http://qooxdoo.678.n2.nabble.com/the-contrib-site-tp7580681p7580754.html Sent from the qooxdoo mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Re: [qooxdoo-devel] the contrib site
Tobi, thanks for the pointer. Can you give some details on what you like and how the new solution addresses the problems? T. On 07/20/2012 12:50 AM, Tobias Oetiker wrote: > after the plugins.jquery.com desaster, the folks there seem to have > come up with a pretty nice system to replace it ... it is not yet > live it seems, but the concept for integrating plugins seems very > neat ... no shame in copying it ... > > https://github.com/jquery/plugins.jquery.com/ > > cheers > tobi > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
