| ../irclogs/#mantishelp.2009-06-25.log | ||
| --- scribe started --- | 00:00 | |
| [KK]Kirill | vboctor: lo | 03:37 |
|---|---|---|
| vboctor | hi [KK]Kirill | 03:48 |
| dhx_m | hi | 15:24 |
| mantisbot | New bug: Bug 10623 - czerwinski1977 - open - new | 15:26 |
| mantisbot | New bug: Coding typo in documented config parameter $g_reminder_recipients_monitor_bug - http://www.mantisbt.org/bugs/view.php?id=10623 | 15:26 |
| nuclear_eclipse | hi dhx_m | 15:45 |
| dhx_m | nuclear_eclipse: I'm detecting some big problems here with anonymous access | 15:45 |
| * nuclear_eclipse hides | 15:45 | |
| dhx_m | nuclear_eclipse: unless of course I am misinterpreting things wrong | 15:46 |
| dhx_m | when you specify an anonymous user account... Mantis thinks anonymous users are real users | 15:46 |
| dhx_m | and thus they can modify their account | 15:46 |
| dhx_m | is that intended? | 15:46 |
| nuclear_eclipse | yes/no | 15:46 |
| dhx_m | I notice this doesn't affect mantisbt.org probably because an anonymous user account isn't specified? | 15:47 |
| nuclear_eclipse | it's generally encourage to set the anonymous user as "protected" | 15:47 |
| nuclear_eclipse | but yes, it's by design to treat anonymous users as if they were logged into the specified account, so that things like access levels and such can be fine-tuned to the site's needs | 15:48 |
| dhx_m | I'm confused though | 15:50 |
| dhx_m | are there two types of anonymous access | 15:50 |
| dhx_m | one where the user has a user_id and one where they don't? | 15:50 |
| dhx_m | I can only really see the need for an anonymous ON/OFF switch | 15:51 |
| dhx_m | and anonymous users get an access level of 0 (ANYBODY) | 15:51 |
| nuclear_eclipse | there is no anonymous mode (afaik) that doesn't have a user_id associated with it.... | 15:53 |
| nuclear_eclipse | afaik, anonymous access requires specifying a user account for access | 15:53 |
| nuclear_eclipse | anywho, it's lunchtime, bbiab | 15:54 |
| dhx_m | what I'm confused about then is how mantisbt.org is configured... because on my installation with $g_anonymous_access defined, anonymous users see "My Account" in the menu | 15:54 |
| dhx_m | I was half way through writing a patch to fix all those issues when I got confused about why mantisbt.org doesn't behave like that | 15:55 |
| nuclear_eclipse | dhx_m: I believe that's a result of you not setting the anonymous account as protected | 15:55 |
| dhx_m | nuclear_eclipse: ah... that should be by default | 15:55 |
| dhx_m | nuclear_eclipse: is there any time when an anonymous account wouldn't be protected? | 15:56 |
| nuclear_eclipse | I dunno | 15:56 |
| dhx_m | it sounds to me like "anonymous" is really just a protected account | 15:56 |
| dhx_m | is there anything else special about protected accounts, other than only admins can modify them? | 15:58 |
| dhx_m | reading the limited documentation on that topic... it seems that is the case | 15:59 |
| dhx_m | now I see why you wanted to redo the auth system! :p | 16:01 |
| dhx_m | lol @ account_prefs_reset.php | 16:59 |
| dhx_m | it seems you can delete anyone's preferences | 16:59 |
| paul_ | dhx_m: yes you can | 17:06 |
| paul_ | dhx_m: you can probably do other things too | 17:06 |
| dhx_m | I'll roll it into my patch | 17:06 |
| dhx_m | I'm fixing up anonymous access | 17:06 |
| paul_ | the fix is to add the session api stuff | 17:06 |
| paul_ | or form api or whatever | 17:06 |
| dhx_m | hmm | 17:06 |
| paul_ | i.e. | 17:07 |
| dhx_m | the problem here is: | 17:07 |
| paul_ | there are 35 locations where we have a comment: # helper_ensure_post(); | 17:07 |
| dhx_m | a) we're sharing account_prefs_* with the manage_ pages | 17:07 |
| paul_ | that comment should be replaced with: | 17:07 |
| paul_ | form_security_validate( 'account_pref_reset' ); | 17:07 |
| paul_ | and the form that generates that page | 17:07 |
| paul_ | should have a form_security_something( 'account_pref_reset'); | 17:08 |
| dhx_m | is that to fix cross site scripting? | 17:08 |
| paul_ | yes | 17:08 |
| dhx_m | but that is separate from the bug I pointed out right? | 17:08 |
| paul_ | i'd say probably not | 17:08 |
| paul_ | as the form_security_ passes in an extra id so you know hwere it came from | 17:09 |
| dhx_m | so form_security_something would also check if the user is allowed to make changes? | 17:09 |
| paul_ | I guess there's still an issue that we should check your a manager | 17:09 |
| paul_ | and that its your account | 17:09 |
| dhx_m | yeah I was wondering if that goes into the XSS form_security_ functions... or we keep that separate | 17:09 |
| dhx_m | I guess those form_security_ things just make sure you've got a correct session hash or something of that nature | 17:10 |
| paul_ | but yea good spot | 17:10 |
| paul_ | that page needs to check | 17:11 |
| dhx_m | yep will fix | 17:11 |
| paul_ | a) id = current_user_id | 17:11 |
| paul_ | or | 17:11 |
| paul_ | user has admin / whatever access | 17:11 |
| dhx_m | I'm copying from account_prefs_update | 17:11 |
| paul_ | seperately to that | 17:11 |
| paul_ | we need to fix the form stuff | 17:11 |
| dhx_m | which btw (account_prefs_update) checks for manage_user_threshold THEN checks for admin_site_threshold... ie. WHAT THE HELL!?! :p | 17:11 |
| * paul_ dislikes admin_site_threshold | 17:12 | |
| dhx_m | another question I had is... do we allow people with manage_user_threshold to update accounts beyond manage_user_threshold? | 17:12 |
| dhx_m | I recon those with manage_user_threshold should only be able to edit accounts at or below their access level | 17:13 |
| dhx_m | hmm | 17:13 |
| dhx_m | actually that doesn't really work | 17:13 |
| dhx_m | I think we already have some check in place so that only administrators can make other people administrators | 17:14 |
| dhx_m | but you can still reset the preferences of admins heh | 17:14 |
| paul_ | bbiab | 17:14 |
| dhx_m | ok | 17:14 |
| * nuclear_eclipse laughs at dhx for stumbling down the rabbit hole... | 17:15 | |
| dhx_m | lol | 17:15 |
| dhx_m | I always knew web scripts (PHP in particular) were a security engineer's worst nightmare | 17:16 |
| dhx_m | at least Mantis checks user input! :p | 17:17 |
| dhx_m | paul_: can you please check this URL: http://www.mantisbt.org/bugs/account_delete.php!disabled! :p | 17:34 |
| dhx_m | sanitised for safety reasons just in case lol | 17:34 |
| paul_ | ? | 17:39 |
| dhx_m | it seems like you can delete your own account without confirmation | 17:41 |
| dhx_m | another case of needing XSS protection | 17:42 |
| paul_ | there are 35 locations where we have a comment: #helper_ensure_post(); | 17:42 |
| paul_ | that comment should be replaced with: | 17:42 |
| paul_ | form_security_validate( 'account_pref_reset' ); | 17:42 |
| paul_ | and the form that generates that page | 17:42 |
| paul_ | should have a form_security_something( 'account_pref_reset'); | 17:42 |
| dhx_m | yep... no helper_ensure_post in account_dlete | 17:44 |
| dhx_m | there is a helper_ensure_confirmed? | 17:44 |
| paul_ | dead iirc | 17:45 |
| paul_ | or maybe it's both | 17:45 |
| dhx_m | also should anonymous users really see the "My View" page? | 17:46 |
| nuclear_eclipse | I don't see why they shouldn't... | 17:46 |
| dhx_m | well it doesn't provide much useful information to them | 17:47 |
| nuclear_eclipse | well, yes/no | 17:47 |
| dhx_m | and the use of the word "My" is not particularly good... because it isn't their view... it is a global view | 17:47 |
| nuclear_eclipse | I think you're arguing more of what should be the default page :P | 17:47 |
| dhx_m | ah I see, we'd have to fix that too | 17:48 |
| dhx_m | so it isn't really worth the effort then :p | 17:48 |
| nuclear_eclipse | I've never liked the wording of 'My View' anyways, because it's not anything you as a user can customize.... | 17:48 |
| dhx_m | a holdover from the Windows ME days? :p | 17:50 |
| dhx_m | when everything was Me & My | 17:50 |
| dhx_m | now it is You & We ;/ | 17:50 |
| dhx_m | I'm personally holding out for what Web 3.5 will bring us | 17:51 |
| * paul_ looks around | 18:02 | |
| paul_ | nuclear_eclipse: did you see my mail? | 18:09 |
| nuclear_eclipse | which one? | 18:28 |
| dhx_m | nuclear_eclipse: can you create a new 1.2.x version on mantisbt.org? | 18:28 |
| paul_ | nuclear_eclipse: about soap | 18:28 |
| paul_ | i'm wondering when to return to mantis coding | 18:28 |
| nuclear_eclipse | dhx_m: new target versio you mean? | 18:29 |
| dhx_m | nuclear_eclipse: yep, so I can target fixes for the 1.2.x branch :) | 18:29 |
| nuclear_eclipse | yeah, I kept meaning to do that and kept forgetting =\ | 18:29 |
| dhx_m | nuclear_eclipse: I guess we need 1.3.x and 1.2.x | 18:29 |
| dhx_m | nuclear_eclipse: not sure what the current 1.x.x is meant for | 18:29 |
| nuclear_eclipse | 1.x.x is the former | 18:30 |
| dhx_m | ok | 18:30 |
| paul_ | how many bugs in 1.2 have we had | 18:30 |
| paul_ | nuclear_eclipse: the one about soap | 18:30 |
| nuclear_eclipse | dhx_m: done | 18:30 |
| dhx_m | nuclear_eclipse: thanks | 18:30 |
| paul_ | can someone modify things | 18:31 |
| paul_ | so users can't comment on resolved/closed bugs | 18:31 |
| paul_ | and can reopen them | 18:31 |
| mantisbot | New bug: Bug 10624 - dhx - open - assigned | 18:32 |
| mantisbot | New bug: Anyone can reset the account preferences of any other user - http://www.mantisbt.org/bugs/view.php?id=10624 | 18:32 |
| nuclear_eclipse | for commenting, I prefer to leave it the way it is, but I'll look into making it so that users can reopen -- I thought they could already though... | 18:32 |
| dhx_m | I'm just making tickets for the commit I'll make in a moment :) | 18:32 |
| paul_ | well | 18:32 |
| paul_ | commenting on resolved bugs is silly | 18:32 |
| nuclear_eclipse | not really | 18:32 |
| paul_ | at lesat if you want a response | 18:32 |
| nuclear_eclipse | a) user could simply be saying thank you, or b) user could be asking what to do to get the fix | 18:33 |
| paul_ | or c) user could be saying fix doesn't work | 18:33 |
| paul_ | and in all 3 cases | 18:33 |
| nuclear_eclipse | neither of those should entail reopeing an issue, which would imply that the issue is not really fixed... | 18:33 |
| paul_ | there information is not going to get read | 18:33 |
| paul_ | necessarily | 18:33 |
| nuclear_eclipse | well, for c) that's what reopen is for | 18:33 |
| paul_ | and for a/b | 18:35 |
| paul_ | my point is | 18:35 |
| paul_ | there's no way within system to tell that a user has added feedback to a bug you've resolved | 18:35 |
| paul_ | so therefore there feedback is likely to get missed | 18:36 |
| nuclear_eclipse | emails | 18:36 |
| paul_ | that's imo a problem if they are telling us there's still a problem | 18:36 |
| nuclear_eclipse | that's what reopen is for... | 18:36 |
| paul_ | you imply that I receive/send emails on bugs :P | 18:37 |
| mantisbot | New bug: Bug 10625 - dhx - open - assigned | 18:37 |
| mantisbot | New bug: The anonymous user account should always be a protected account - http://www.mantisbt.org/bugs/view.php?id=10625 | 18:37 |
| paul_ | anyway | 18:37 |
| paul_ | nuclear_eclipse: is victor right on the soap thing? | 18:37 |
| * nuclear_eclipse just set repoen threshold to REPORTER | 18:37 | |
| paul_ | thank you ;p | 18:38 |
| nuclear_eclipse | re soap, let me re-read the email - I was rather confused when I read it the first time | 18:38 |
| CIA-18 | Mantisbt: hickseydr * r3803c90c340d / (11 files in 3 dirs): Anonymous accounts: fixes and doc updates | 18:39 |
| dhx_m | backport? | 18:39 |
| nuclear_eclipse | nah | 18:40 |
| nuclear_eclipse | we already said 1.1.8 was the last 1.1.x release :P | 18:41 |
| dhx_m | nah I meant backport to 1.2 :p | 18:41 |
| nuclear_eclipse | oh, right, then yes | 18:41 |
| dhx_m | ok :) | 18:41 |
| nuclear_eclipse | `git cherry-pick` ftw | 18:41 |
| dhx_m | hmm now I have to work out how to add remote branches | 18:42 |
| paul_ | :) | 18:42 |
| mantisbot | New bug: Bug 10626 - dhx - open - assigned | 18:42 |
| mantisbot | New bug: Improve documentation relating to anonymous user accounts - http://www.mantisbt.org/bugs/view.php?id=10626 | 18:42 |
| nuclear_eclipse | paul_: isset() in the new context of mc_* is not needed, ie, it will always return true because you are now passing it a valid value | 18:43 |
| paul_ | which is now a bug ;p | 18:43 |
| paul_ | i think | 18:43 |
| * paul_ hates soap api | 18:43 | |
| nuclear_eclipse | dhx_m: `git checkout origin/<branch> <branch>` | 18:43 |
| dhx_m | thanks :) | 18:43 |
| nuclear_eclipse | paul_: no, because the bugobject will always have a default value for those fields | 18:43 |
| paul_ | can I work on soap api with my sledgehammer? | 18:44 |
| aptituz_ | 20:41 < nuclear_eclipse> we already said 1.1.8 was the last 1.1.x release :P | 18:44 |
| aptituz_ | *sigh* | 18:44 |
| paul_ | ? | 18:45 |
| paul_ | why are you sighing? | 18:45 |
| nuclear_eclipse | aptituz_: :P | 18:45 |
| aptituz_ | sounds like there will be support work for me, once its out | 18:45 |
| nuclear_eclipse | aptituz_: we can't help it that Debian moves slower than even Mantis development :P | 18:45 |
| dhx_m | lol | 18:46 |
| dhx_m | ... slower than RHEL?! :o | 18:46 |
| aptituz_ | i guess I wont mantain mantis over the sqeeze release cycle | 18:46 |
| dhx_m | brb, installing Slackware | 18:46 |
| nuclear_eclipse | squeeze? | 18:46 |
| nuclear_eclipse | oh, lenny+1? | 18:46 |
| dhx_m | I thought 1.1.x would be maintained for major security problems? | 18:47 |
| dhx_m | until 1.2 final is out? | 18:47 |
| nuclear_eclipse | dhx_m: how major of a security problem is this? | 18:47 |
| * nuclear_eclipse has been not paying much attention | 18:47 | |
| dhx_m | nuclear_eclipse: nah I'm not talking about my last fix... just in general | 18:47 |
| dhx_m | nuclear_eclipse: just resetting the user preferences on any user account you want (even as an anonymous user) | 18:48 |
| nuclear_eclipse | it'd have to be a pretty big security issue at this point to warrant another release... | 18:48 |
| nuclear_eclipse | user prefs including realname/password? | 18:48 |
| dhx_m | nuclear_eclipse: no | 18:48 |
| aptituz_ | dhx_m: well does not help much if support for mantis dies once its out | 18:48 |
| nuclear_eclipse | then not very big :P | 18:48 |
| dhx_m | nuclear_eclipse: nope, just annoying :) | 18:49 |
| nuclear_eclipse | dhx_m: if it's easy to port to 1.1.x, I say go ahead, we don't actually have to make an official release of it :P | 18:49 |
| aptituz_ | that release behaviour is somewhat like making a baby and not supporting it anymore when the next ones come | 18:50 |
| nuclear_eclipse | aptituz_: we can barely support the new baby :P | 18:50 |
| aptituz_ | seems so | 18:50 |
| nuclear_eclipse | and tbh, we offer more/longer support on stable releases than most web app projects... | 18:50 |
| dhx_m | nuclear_eclipse: I'll check | 18:51 |
| aptituz_ | probably distros that are meant to be used on servers shall not mantain mantis anymore | 18:51 |
| paul_ | well, whilst i'm sure we'd do a security fix if something came up (and it was sensible/easier enough to do one) | 18:52 |
| paul_ | at the same time | 18:52 |
| nuclear_eclipse | it's quite unfortunate, but the fast pace of web-app development just doesn't seem to mesh well with the rigid release cycles for native software distributions... =\ | 18:52 |
| paul_ | in 1.2.x, the api's have been changed around to be more secure by default | 18:52 |
| paul_ | and do extra checking to try to reduce future risks a little | 18:52 |
| nuclear_eclipse | aptituz: fast pace in this context being the lack of organization in the project... | 18:53 |
| dhx_m | aptituz: at some point you have to just move on from the past to get away from poor architecture, buggy-by-design coding, etc | 18:54 |
| aptituz | nuclear_eclipse: its not that rigid, when people actually try to use software | 18:54 |
| nuclear_eclipse | aptituz: I mean rigid in the context of scheduled feature freezes, etc | 18:55 |
| dhx_m | aptituz: 1.1 to 1.2 in Mantis is similar to say 2.6.29 -> 2.6.30 in the Linux kernel | 18:55 |
| aptituz | nuclear_eclipse: it wouldn't help much, if a distribution wouldn't have a feature freeze | 18:55 |
| nuclear_eclipse | agreed | 18:55 |
| aptituz | dhx_m: i do not really care | 18:55 |
| nuclear_eclipse | I just mean that peripheral applications don't tend to mesh well into a Linux distribution -- it's a matter of clashing priorities | 18:56 |
| aptituz | dhx_m: its a thing of politics. if mantis doesn't take itself serious enough to support a version longer then a year, then its definitely not worth the attention of a distribution | 18:56 |
| aptituz | dhx_m: you forget that the distribution has to support that work, too | 18:56 |
| nuclear_eclipse | like I said, clashing priorities :P | 18:56 |
| aptituz | no, thats no clashing of priorities | 18:56 |
| nuclear_eclipse | it's not a matter of taking ourselves serious, it's a matter of effort and priorities | 18:56 |
| aptituz | thats just lack of organization, lack of a proper release management | 18:57 |
| nuclear_eclipse | organization and management requires time and effort -- mantis has little of both | 18:57 |
| aptituz | well, that is particular true for most distros | 18:57 |
| paul_ | aptituz: do you bundle wordpress? or phpbb? or moodle or whatever? | 18:58 |
| aptituz | just that a maintainer has to take care for several projects at once (next to their daily jobs) and you have to care for one | 18:58 |
| aptituz | paul_: no | 18:58 |
| nuclear_eclipse | so in our case, our priorities are on moving forward, not spending all of our little time on supporting old releases | 18:58 |
| dhx_m | aptituz: personally I tend to prefer the Gentoo style of approach to release management | 18:58 |
| aptituz | paul_: why should I? I have enough trouble with mantis to be served for the next 10 years ;) | 18:58 |
| paul_ | well | 18:59 |
| paul_ | I think we'd release a 1.1.9 if a security issue came up and was reported | 18:59 |
| dhx_m | aptituz: you seem to be taking a very traditional view on version numbering... ie, not an iterative development process | 18:59 |
| paul_ | but | 18:59 |
| paul_ | at the same time | 18:59 |
| aptituz | so you think your users have to move forward each time you feel overwhelmed with supporting two (!) releases? | 18:59 |
| paul_ | if I spot some code that I think might be an issue and fix it | 18:59 |
| paul_ | I probably wont spend the time to see if it might have been an issue in 1.1 | 18:59 |
| aptituz | mantis isn't meant to be used in professional areas, is it? | 18:59 |
| dhx_m | dhx_m: many projects thesedays (including the Linux kernel) take an iterative approach where changes are applied incrementally and old cruft is phased out continuously with X months warning, etc | 19:00 |
| dhx_m | hmmm talking to myself | 19:00 |
| aptituz | lol | 19:00 |
| aptituz | dhx_m: you cannot really compare a kernel to a web application | 19:00 |
| paul_ | what web apps does debian bundle :) | 19:00 |
| aptituz | its different in size and in importance | 19:01 |
| nuclear_eclipse | squirrelmail, for one | 19:01 |
| dhx_m | aptituz: yes you can... same development model... incremental change is the focus | 19:01 |
| aptituz | and even if other webapps do it worse, it doesn't mean that you have to | 19:01 |
| aptituz | dhx_m: no, you can't. because they are totally different applications. | 19:01 |
| aptituz | dhx_m: as an example: if mantis would be properly maintained upstream, then maintaining it for a distribution is a one-person-job | 19:02 |
| aptituz | dhx_m: on the other hand, maintaining the kernel - as a central component of the system - is not, has never been and will never be a one-person jobb | 19:02 |
| aptituz | if you already have the power at all places, you can act this way | 19:02 |
| aptituz | dhx_m: and on the other side: old kernels are _still_ supported by upstream | 19:03 |
| dhx_m | aptituz: I can understand where you are coming from... but what is your threshold at which you consider something needing to be fixed in an old version? | 19:03 |
| dhx_m | aptituz: they don't release 2.6.28.X anymore though | 19:03 |
| aptituz | dhx_m: security at least. we don't allow other fixes in, in Debian, so its not much I ask for | 19:03 |
| nuclear_eclipse | aptituz: there are also more people on each *distro* supporting old kernels than we have supporting development just on our primary version... | 19:03 |
| aptituz | dhx_m: but I cannot count on an upstream saying "we will _eventually_ fix bugs as they arise" | 19:04 |
| dhx_m | aptituz: that is something that nuclear_eclipse and paul (and myself) have already said would happen | 19:04 |
| aptituz | dhx_m: no, they said, they would do it, if it happens to be known | 19:04 |
| aptituz | dhx_m: and that they won't look if a given bug also affects their previous release | 19:04 |
| aptituz | dhx_m: that is entireley different | 19:04 |
| paul_ | aptituz: one of the things we've done with 1.2 | 19:05 |
| dhx_m | aptituz: well as I understand it, you want to package 1.1.5 or something and apply patches to 1.1.5 instead of upgrading to 1.1.6 that includes those patches? | 19:05 |
| paul_ | is moved to using parametized queries | 19:05 |
| paul_ | i.e. | 19:05 |
| aptituz | 21:03 < dhx_m> aptituz: they don't release 2.6.28.X anymore though <- yeah, but they releases 2.4.37.2 a few month ago | 19:05 |
| aptituz | s/releases/released/ | 19:05 |
| nuclear_eclipse | o rly? | 19:05 |
| paul_ | we've replaced db_query("SELECT * FROM TABLE where id = " . db_param_string($foo)); | 19:06 |
| paul_ | with: | 19:06 |
| paul_ | db_query_bound("SELECT * FROM TABLE WHERE id=" . db_param(), array($foo ) ); | 19:06 |
| nuclear_eclipse | aptituz: was that an official release, or a distro-supported release? | 19:06 |
| paul_ | so my point is | 19:06 |
| aptituz | nuclear_eclipse: its a release on kernel.org, so its surely not a distro release | 19:06 |
| dhx_m | aptituz: but they're treating them as fairly separate products... | 19:07 |
| paul_ | given the internals have changed | 19:07 |
| nuclear_eclipse | hmm, nifty :) | 19:07 |
| aptituz | dhx_m: so what? | 19:07 |
| paul_ | 1.1 is effectively a completely different set of code to 1.2 | 19:07 |
| dhx_m | aptituz: how many old versions of 2.6 are they supporting? | 19:07 |
| aptituz | dhx_m: I didn't ask for implementing features on top of 1.1.x | 19:07 |
| paul_ | so my point was | 19:07 |
| nuclear_eclipse | paul_: especially after you changed just about everything everywhere in some form or manner... | 19:07 |
| paul_ | if a security issue comes up in 1.1 | 19:07 |
| aptituz | so if a security issue comes up in 1.1 you feel overwhelmed? | 19:07 |
| paul_ | it'll likely get looked at / fixed (as that's worth us doing) | 19:08 |
| aptituz | you as the one who actually knows the code best? | 19:08 |
| dhx_m | aptituz: software engineering normally argues that lack of features are also defects... | 19:08 |
| aptituz | but the distros should handle it? | 19:08 |
| aptituz | thats just not the way it _can_ work | 19:08 |
| paul_ | nuclear_eclipse: how can I diff 1.1 v 1.2 ? | 19:08 |
| * dhx_m goes back to Gentoo :p | 19:09 | |
| paul_ | anyway, my personal point is | 19:09 |
| nuclear_eclipse | paul_: `git diff master-1.1.x..master-1.2.x` :P | 19:09 |
| aptituz | dhx_m: thats not always true for businesses who actually use the software | 19:09 |
| paul_ | where we've changed a lot of the core api's | 19:09 |
| paul_ | and 2-3 people have reformatted code | 19:09 |
| paul_ | etc etc | 19:09 |
| aptituz | dhx_m: a lot of companies cannot effort to re-evaluate, re-rollout etc. a software every now and then just because a feature they eventually won't ever use comes up | 19:09 |
| paul_ | if I looked at 1.1, to an extent it would almost be looking at 'new code' | 19:10 |
| aptituz | paul_: I _do_ understand that point. The point is, that it cannot go this way | 19:10 |
| dhx_m | aptituz: my point before is that RHEL might pick 2.6.28.x as their stable kernel for the next 4 years... they're now the ones responsible for maintaining what is essentially a new branch | 19:10 |
| aptituz | paul_: what is if you release 1.2 and work for 1.3? | 19:10 |
| aptituz | paul_: will you release 1.2 again for half a year and then drop support? | 19:10 |
| aptituz | and argue the same way "we've changed so much" | 19:10 |
| aptituz | I guess you will | 19:10 |
| paul_ | well what if we did quaterly releases | 19:11 |
| paul_ | say instead of 1.1 and 1.2 | 19:11 |
| paul_ | we did | 19:11 |
| dhx_m | aptituz: but the kernel developers themselves aren't going to be maintaining an arbitrary set of branches for dozens of distros and users... they're going to be working on a single branch | 19:11 |
| paul_ | 2009.01 | 19:11 |
| paul_ | 2009.06 | 19:11 |
| aptituz | dhx_m: so you think a distribution should simply go and die and upstreams can do what they want, or what exactly is your point? | 19:11 |
| paul_ | 2009.10 | 19:11 |
| paul_ | or even if 1.2 had been called 1.1.9 | 19:12 |
| paul_ | with a bunch of new features in it | 19:12 |
| dhx_m | aptituz: I'm not quite taking it that far... but to say it is the responsibility of upstream to maintain dozens of branches is going too far IMO | 19:12 |
| aptituz | dhx_m: nobody asked for "dozens of upstream" | 19:12 |
| dhx_m | aptituz: it is fair for upstream to help provide patches for important issues | 19:12 |
| aptituz | dhx_m: but it should be possible to support at least _one_ stable version for more then a year | 19:13 |
| aptituz | software that _has_ to be upgraded every _year_ is actually unusable | 19:13 |
| paul_ | in a sense | 19:13 |
| aptituz | dhx_m: _can_ is okay, _can_ is what people are used, but abandoning upstream support makes it a _must_ | 19:13 |
| paul_ | 1.1 has been supported for more then one year | 19:13 |
| nuclear_eclipse | <sarcasm>Just Fork It</sarcasm> :P | 19:14 |
| aptituz | what ever | 19:14 |
| dhx_m | well I agree that we should still provide security fixes for 1.x | 19:14 |
| aptituz | I don't think this discussion leads to anything | 19:14 |
| aptituz | I will just take my mantis maintainer hat in Debian and put it down. The question is just when. | 19:14 |
| paul_ | 1.1.019/12/2007 | 19:14 |
| paul_ | 1.1.119/01/2008 | 19:14 |
| paul_ | 1.1.217/06/2008 | 19:14 |
| paul_ | 1.1.314/10/2008 | 19:14 |
| paul_ | 1.1.418/10/2008 | 19:14 |
| paul_ | 1.1.521/11/2008 | 19:15 |
| paul_ | 1.1.609/12/2008 | 19:15 |
| paul_ | 1.1.720/04/2009 | 19:15 |
| paul_ | 1.1 has lasted since december 2007 | 19:15 |
| paul_ | and 1.2 isn't out yet | 19:15 |
| paul_ | so about 18-19 months | 19:15 |
| paul_ | i'm not really sure what you want done | 19:16 |
| paul_ | I've already said that we'd fix security issues in 1.1 | 19:16 |
| dhx_m | I think he wants us to support THE version used in Debian version X for at least 1 year | 19:16 |
| aptituz | paul_: so, you actually supported 1.1.0 for longer then a year - fine, my point is mood, with 1 year | 19:16 |
| dhx_m | so if they chose 1.1.5, we'd need to support it a whole year (not from 1.1.0) | 19:16 |
| paul_ | I've also said that where we have done some large api changes, it's likely that issues in 1.1 and 1.2 would be different | 19:17 |
| paul_ | so from debian's point of view | 19:17 |
| paul_ | if a security issue came up in 1.1 I think we'd need to deal with it | 19:17 |
| paul_ | that would be the responsible thing to do and also what's expected | 19:17 |
| paul_ | and I'd suspect we'd deal with it fairly promptly | 19:17 |
| paul_ | at the same time | 19:17 |
| dhx_m | paul_: think of it like having a "debian-etch" branch in git that we backport important fixes to? | 19:17 |
| paul_ | every 3-6 months I tend to run some tools to look for security issues in mantis | 19:18 |
| paul_ | e.g. the automated web-testing tools you can get | 19:18 |
| aptituz | paul_: from Debians point of view mantis is a project with a gigantic backlog regarding to trouble with a gigantic support effort neccessary to support it | 19:18 |
| aptituz | paul_: and you say "oh no, we don't want to know about our old work anymore" | 19:18 |
| paul_ | I'm *unlikely* to run them against 1.1 | 19:18 |
| paul_ | (mainly as when I do it, it tends to take a good day to do | 19:19 |
| aptituz | in fact more then 3 maintainers stepped down from maintaining mantis because its actually not possible | 19:19 |
| aptituz | you don't make it better this way | 19:19 |
| aptituz | so, good, if you _can't_, as you say, then mantis should probably just not be part of a distribution, as I already said earlier | 19:19 |
| paul_ | i'm trying to work out really what a good web app would do | 19:20 |
| paul_ | or more | 19:20 |
| aptituz | maybe someone is willing to provide support for mantis, when I orphan it, but I don't think he will do it for a long time | 19:20 |
| dhx_m | aptituz: doesn't Debian maintain it's own branch of the kernel though? | 19:20 |
| paul_ | one observation I've got is | 19:20 |
| paul_ | web apps and security issues surrounding them seem to change (as new techniques come out etc) | 19:21 |
| aptituz | dhx_m: sure. but I already told you that a kernel is a more fundamental component of a distribution, that needs love of many _from the beginning_ | 19:21 |
| aptituz | dhx_m: how should a single person support such a small project as a webapp, if even $upstream (with more then 1 developer) can? | 19:21 |
| dhx_m | aptituz: yep but the point is that maintaining the kernel is a huge task that is performed by the Debian project rather than Linus or Andrew | 19:21 |
| aptituz | dhx_m: and if this project is that small: why should more persons support it? | 19:21 |
| aptituz | dhx_m: no, I don't think that it is entireley so | 19:22 |
| aptituz | dhx_m: I'm not involved in kernel development, but a) kernel.org does maintenance releases of older versions b) kernel.org devs are (surely) involved with fixing issues in the distributions | 19:23 |
| dhx_m | aptituz: "involved" could mean that they have a look at old code and see what the problem is... but their ultimate aim would still be to fix the latest version rather than an old version | 19:24 |
| aptituz | dhx_m: one could even use 2.4 if he wants to, because it has been updated just about 14 days ago | 19:24 |
| aptituz | dhx_m: are you involved with kernel maintenance either upstream or in a distribution? | 19:25 |
| aptituz | dhx_m: because I find it kind of mood to discuss something we do know not much about | 19:25 |
| aptituz | dhx_m: and personally I really don't know more, except the obvious | 19:26 |
| dhx_m | aptituz: no I'm not involved beyond being interested in how it all works | 19:26 |
| aptituz | and my impression from the outside is, that the kernel is better supported by upstream, as anyone would ever except from mantis | 19:26 |
| aptituz | eh | 19:26 |
| aptituz | s/except/expect/ | 19:26 |
| dhx_m | aptituz: well let me put it this way... Debian has created a branch/fork of Mantis from version X and they've created rules on that branch | 19:27 |
| aptituz | dhx_m: because compared to the kernel: asking for the same support would mean supporting 2 versions parallel for more then 5 years (!) | 19:27 |
| paul_ | i'm trying to work out how your ideal webproject would work | 19:27 |
| dhx_m | aptituz: rules such as "it will only be modified in the event of a known security problem" | 19:27 |
| dhx_m | aptituz: now you're asking Mantis developers to maintain your own branch? | 19:28 |
| aptituz | paul_: synchronized to the major distros would be a good start | 19:28 |
| aptituz | dhx_m: eh? I try to stick with $upstream, but thats entirely impossible to do, if upstream decides to release every now and then and after that drop support for older releases more or less entireley | 19:29 |
| dhx_m | aptituz: when Debian packages a new version of the kernel, I imagine the patch is created by someone from within the Debian kernel team... rather than a key Linux developer (overlap may exist of course) | 19:29 |
| aptituz | saying "we will eventually fix issues" is much less then saying "Hey we will make a maintenance release now and then and backport patches if appropriate" | 19:29 |
| aptituz | dhx_m: _packaging_ | 19:29 |
| nuclear_eclipse | aptituz: other than supporting security fixes on old branches, what else would you like to see us do? | 19:30 |
| aptituz | dhx_m: again: its mood to talk about things we don't know | 19:30 |
| aptituz | nuclear_eclipse: nothing, except maybe not pretending "thats devils work we never made" | 19:31 |
| aptituz | and just btw: As a package maintainer I _also_ have to support to versions of mantis | 19:32 |
| nuclear_eclipse | well, I wouldn't say that's a fair representation of our views on old branches... | 19:32 |
| aptituz | s/to/too/ | 19:32 |
| aptituz | arg | 19:32 |
| aptituz | s/too/two/ | 19:32 |
| aptituz | i'am not able to talk anymore, today ;) | 19:32 |
| paul_ | hmm | 19:32 |
| paul_ | i'd still like to know how other web apps handle things | 19:32 |
| paul_ | if they are doing it well | 19:32 |
| paul_ | as from what I can tell | 19:32 |
| paul_ | different distributions have their own release dates/cycles | 19:32 |
| paul_ | some update stuff all the time | 19:33 |
| paul_ | others try to stay on 'old' stable versions | 19:33 |
| aptituz | nuclear_eclipse: well not entireley, but you have to admit that a lot of work sticked with the distro maintainers with older releases of mantis | 19:33 |
| aptituz | (besides working out all the problems that mantis has besides that thematic) | 19:33 |
| paul_ | so i'm not sure where | 19:34 |
| nuclear_eclipse | aptituz: I can't speak for 1.0.x because I joined mantis after 1.1.0a3 was already a huge jump from 1.0.x, but I can say that I do want to support 1.1.x -- my comment earlier was just that we've said that 1.1.8 would be the last non-security-related release of 1.1.x | 19:34 |
| aptituz | and btw. if you say that you are willing to look into bugs, try to fix them and do some maintenance releases that would be a better situation as the one you stated, when we started the discussion | 19:34 |
| paul_ | 0.19->1.0 = 500 days, 1.0->1.1 = 683 days, and 1.1->1.2 = 550 days | 19:34 |
| paul_ | whether we want shorter releases | 19:35 |
| paul_ | or longer releases | 19:35 |
| paul_ | or what ;/ | 19:35 |
| aptituz | because you said "1.1.8 is the last 1.1.x version we released" | 19:35 |
| dhx_m | "development on the 1.1.x series will be halted as of now, barring any major issues before the final release of 1.2.0." | 19:36 |
| aptituz | paul_: heh, indeed, looking at the blank numbers as you state them it seems quiet good | 19:36 |
| aptituz | dhx_m: sounds better, then "20:41 < nuclear_eclipse> we already said 1.1.8 was the last 1.1.x release :P | 19:37 |
| paul_ | aptituz: the problem I find with our current 500 days is | 19:37 |
| paul_ | it's quite 'slow' in a sense | 19:37 |
| paul_ | so releases turn into nightmares | 19:37 |
| nuclear_eclipse | aptituz: that was more of a tongue-in-cheek comment, really | 19:38 |
| paul_ | as we try to do *too much* in them | 19:38 |
| paul_ | but then if we did 6 monthly releases | 19:38 |
| aptituz | another problem is that early releases often are bareley useable ;) - i just remember how broken 0.19 was. | 19:38 |
| paul_ | i'm not sure if that would be less or more of a problem | 19:38 |
| * nuclear_eclipse doesn't even remember 1.0.x... :P | 19:38 | |
| paul_ | aptituz: there was 684 days between 0.18 and 0.19 | 19:39 |
| aptituz | paul_: I guess then that its eventually just a timing problem | 19:39 |
| paul_ | but at the same time | 19:39 |
| paul_ | if you take the 1.0.0 to 1.1.0 ( 683 days) | 19:39 |
| aptituz | so eventually 1.1.x should not have made it into Lenny and the next release should just wait for 1.3 and pick it early | 19:39 |
| paul_ | between those 2 releases | 19:39 |
| paul_ | we had: | 19:39 |
| paul_ | 1.0.118/02/200614 | 19:40 |
| paul_ | 1.0.218/04/200659 | 19:40 |
| paul_ | 1.0.307/05/200619 | 19:40 |
| paul_ | 1.0.422/07/200676 | 19:40 |
| paul_ | 1.0.523/07/20061 | 19:40 |
| paul_ | 1.1.0a111/09/200650 | 19:40 |
| paul_ | 1.0.628/10/200647 | 19:40 |
| paul_ | 1.0.728/10/20060 | 19:40 |
| paul_ | 1.1.0a207/12/200640 | 19:40 |
| paul_ | 1.1.0a308/05/2007192 | 19:40 |
| paul_ | 1.0.801/07/2007206 | 19:40 |
| paul_ | 1.1.0a401/08/200785 | 19:40 |
| paul_ | 1.1.0rc102/08/200732 | 19:40 |
| aptituz | but then again, this will not be possible, so I come back to my point that distros should eventually not include mantis ;) | 19:40 |
| paul_ | 1.1.0rc204/10/200764 | 19:40 |
| paul_ | 1.1.0rc323/11/2007113 | 19:40 |
| paul_ | but isn't that the same for a lot of webapps | 19:40 |
| aptituz | maybe | 19:41 |
| aptituz | I'm not involed with other webapps | 19:41 |
| aptituz | its still bad for the users of the apps | 19:41 |
| paul_ | http://wordpress.org/about/roadmap/ | 19:41 |
| aptituz | if maintaining packages from webapps is not able for distros, it means that users have to use upstream packages instead of well-integrated packages, but thats the consequence of release cycles that are contradicting | 19:43 |
| aptituz | paul_: that site does not provide much information for us, because it does not talk about how older releases are supported | 19:44 |
| paul_ | well | 19:45 |
| nuclear_eclipse | not at all :P | 19:45 |
| paul_ | wordpress as soon as a new release comes out | 19:45 |
| paul_ | has an 'update to 2.8' thing in the php script | 19:45 |
| paul_ | you can click on | 19:45 |
| aptituz | and btw. I lack to see how a blog software relates to software thats eventually used by businesses | 19:45 |
| nuclear_eclipse | aptituz: plenty of businesses use wordpress | 19:45 |
| paul_ | aptituz: MS package wordpress for windows for their php stuff | 19:45 |
| paul_ | so i'd say it's a big app | 19:46 |
| aptituz | nuclear_eclipse: I guess that most companies that use blogs (and especially wordpress) know what they are doing and have no other choice (except using a software that isn't as buggy as wordpress, heh) | 19:46 |
| nuclear_eclipse | well, I'm not going to argue that :P | 19:46 |
| paul_ | http://www.microsoft.com/Web/gallery/ | 19:46 |
| paul_ | includes ordpress | 19:46 |
| paul_ | sorry - http://www.microsoft.com/Web/downloads/platform.aspx | 19:46 |
| aptituz | paul_: microsoft uses wordpress? that sounds like two found each other :P | 19:46 |
| aptituz | well | 19:48 |
| aptituz | it all leads to the point where one has to admit that Debians goals and mantis goals are indeed conflicting as nuclear_eclipse said | 19:48 |
| nuclear_eclipse | anyways, aptituz, regardless of any miscommunication we may have had today, security releases are still on the table for 1.1.x | 19:49 |
| aptituz | good | 19:50 |
| dhx_m | nuclear_eclipse: are you able to backport the user prefs reset patch for me? :p | 19:52 |
| dhx_m | nuclear_eclipse: I'm stuck heh | 19:52 |
| nuclear_eclipse | I can probably give it a good try | 19:53 |
| nuclear_eclipse | I need a patch queue :P | 19:53 |
| dhx_m | :) | 19:53 |
| nuclear_eclipse | oh wait! `git format-patch` + bug assigned to me ;) | 19:54 |
| dhx_m | :) | 19:54 |
| nuclear_eclipse | maybe this is something I could develop as a feature for the source-integration plugins, mark patches as being queued for a specific branch.... | 19:55 |
| paul_ | anyway | 20:21 |
| paul_ | i've had a brief break from mantis since rc1 | 20:21 |
| paul_ | might look at soap api a bit at weekend | 20:21 |
| paul_ | or something | 20:21 |
| paul_ | can we see how many times rc1 has been downloaded? | 20:21 |
| dhx_m | http://sourceforge.net/project/stats/detail.php?group_id=14963&ugn=mantisbt&type=prdownload&mode=week&package_id=12175&release_id=692031 | 20:31 |
| nuclear_eclipse | nice | 20:35 |
| nuclear_eclipse | up to rc1, we were still getting a steady number of downloads for 1.2a3 too... | 20:36 |
| nuclear_eclipse | wow: https://sourceforge.net/project/stats/detail.php?group_id=14963&ugn=mantisbt&type=prdownload&mode=week&package_id=166159&release_id=0 | 20:37 |
| nuclear_eclipse | ~400 downloads a day for mantis-stable | 20:38 |
| nuclear_eclipse | hi siebrand | 21:01 |
| siebrand | hola | 21:02 |
| Bran | i'm using the mantis SOAP api to retrieve some simple data, the soap return type for "mc_projects_get_user_accessible" is "ProjectDataArray" | 21:31 |
| Bran | is there a php file i need to include so I can work directly with ProjectDataArray? | 21:31 |
| paul_ | 400? | 22:05 |
| siebrand | repo down? | 22:41 |
| paul_ | boxisp | 22:45 |
| nuclear_eclipse | sorry, never started the git-daemon after the reboot... | 22:46 |
| nuclear_eclipse | or something | 22:46 |
| paul_ | michael jackson died ;/ | 22:46 |
| * nuclear_eclipse goes back into hiding | 22:46 | |
Generated by irclog2html.py